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REMARKS 

This amendment is being filed along with a Request for Continued Examination 
(RCE) application in response to the final Office Action. Claims 1-2, 5-9, and 11-33 are 
canceled herein without prejudice. Claims 3-4 and 10 were previously canceled without 
prejudice. New claims 34-59 are added herein. No new matter has been added. With this 
amendment, claims 34-59 are pending in the application. 

I. Objections 

The Office Action objected to the specification "because it has URLs or browser 
executable code." To address the objection a Substitute Specification (clean copy), along with a 
Redline Substitute Specification showing the changes in redline format, are being submitted 
herewith. The Substitute Specification contains no new matter. 

In the Substitute Specification, the format of the various items such as 
"www.gslb.com" and "www.foo.com" have been amended/altered such that they are no longer 
browser-executable. Specifically, a "space" has been added after each punctuation mark (e.g., 
after each period, dash, etc.) so that a browser would not read said items in the specification as 
executable code. Thus, the newly presented formats in the Substitute Specification are 
"www. gslb. com" and "www. foo. com", for example. It is therefore respectfully submitted that 
the objections in the Office Action have now been properly addressed. 

The Office Action also raised an objection due to a mis-numbering error in claims 
31-33, and requested re-numbering of the claims. Specifically, two claims were mistakenly both 
numbered as claim "31." In view of the cancellation of claims 1-33 and the presentation of new 
claims 34-59 herewith, it is respectfully submitted that this objection due to claim numbering is 
now rendered moot. 

II. Information Disclosure Statement (IDS) 

The Office Action indicated on pages 2-3 that the ten (10) non-published pending 
U.S. patent applications listed in the IDS filed on October 18, 2006 were not in compliance, and 
therefore were not considered. It is respectfully submitted that IDS filing requirements have 
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indeed been met, since copies of said 10 applications were indeed submitted with the October 18, 
2006 IDS filing. 

In a telephone conversation held with the Examiner on November 16, 2006, the 
Examiner explained that the copies of said 10 applications had not yet been electronically loaded 
into the USPTO system when the present Office Action was issued. Hence, the Office Action 
was issued with said 10 applications being indicated to be non-considered in the form PTO-1449. 
However, the Examiner indicated during the telephone conversation that said 10 applications 
now appear in the USPTO system (said 10 applications now appear on PAIR, for example) and 
confirmed that said copies were submitted along with the original October 1 8, 2006 IDS filing, 
and further indicated that he will indicate consideration thereof in the next communication. 
Accordingly, it is kindly requested that the Examiner provide confirmation of entry and 
consideration of these 10 non-published pending U.S. patent applications in the next 
communication. 

Another IDS is being filed herewith, so as to submit new references for entry and 
consideration. Again, it is kindly requested that the Examiner also provide confirmation of entry 
and consideration of these new references in the next communication. Because this present IDS 
is being filed along with an RCE, no fee is required for this present IDS filing. 

III. Discussion of new independent claim 34 and its dependent claims 
The present Office Action appears to have rejected all of the previously presented 
claims under 35 U.S.C. § 102(b) as being anticipated by a white paper entitled "Server Load 
Balancing in Today's Web-Enabled Enterprise" (hereinafter "the White Paper"). In view of the 
cancellation of previously presented claims 1-2, 5-9, and 11-33, these rejections are rendered 
moot. 

New claims 34-59 are being presented herein, and it is respectfully submitted that 
these claims are allowable over the White Paper. Further, the recitations in new claims 34-59 are 
supported by the original specification as filed. A discussion of the distinctiveness of new 
independent claim 34 and its dependent claims over the White Paper will be provided first. 
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New independent claim 34 recites, inter alia, " obtaining at said site switch 
mapping information indicative of a mapping between said private virtual IP address and a 
public virtual IP address" and " providing said mapping information from said site switch to at 
least one load balancing controller to enable said load balancing controller to update an address 
record to indicate said public virtual IP address as a virtual IP address configured at said site 
switch." It is respectfully submitted that these limitations are not met by the White Paper. 

For example, in originally rejecting former claim 14 that recited, inter alia, 
"sending the mapping information for the host servers . . . from the first network device to the 
load balancing device," pages 7-8 of the present Office Action cited page 6, item 4 of the White 
Paper as meeting this and other limitations by disclosing " Authoritative DNS provides a IP 
address information and send to Controller GSLB Switch" and "Controller GSLB Switch 
receives IP address information sent from Authoritative DNS " (emphasis ours). A similar 
interpretation of the White Paper was made in rejecting former claim 1 on page 5 of the present 
Office Action, where the authoritative DNS server was interpreted as sending the mapping 
information to the load balancing device. 

However, new independent claim 34 specifies that the recited "configuring ... a 
private virtual IP address" and "obtaining . . . mapping information" are " at said site switch ," and 
further specifies that the mapping information is provided " from said site switch to said load 
balancing controller ." Accordingly, since claim 34 specifically requires the mapping 
information to be provided from a site switch, the White Paper cannot meet this limitation since 
the authoritative DNS server (and not a site switch) has been interpreted by the Office Action as 
providing mapping information to a load balancing device. Thus, claim 34 is allowable over the 
White Paper. 

Claim 34 further recites, inter alia, "enable said load balancing controller to 
update an address record to indicate said public virtual IP address as a virtual IP address 
configured at said site switch rather than treating said public virtual IP address as a real IP 
address ." It is respectfully submitted that none of these limitations are disclosed, taught, or 
suggested by the White Paper. For example, the White Paper is completely silent as to any 
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address record or updating thereof to indicate a public virtual IP address as a virtual IP address 
configured at a site switch. 

Page 4 of the Office Action asserted that the terms "private VIP address" and 
"public VIP address" are simply associated with IP addresses of a network for limited access and 
"cannot be patentable features." This assertion is respectfully traversed herein. The manner in 
which a private virtual IP address and a public virtual IP address are treated under claim 34 is 
indeed a distinction over the White Paper. That is in claim 34, if mapping information indicative 
of a mapping between a public virtual IP address and a private virtual IP address is provided to 
the load balancing controller, then the address record is updated , so that the public virtual IP 
address is not treated as a real IP address . Dependent claim 37 further elaborates by specifying 
that " public virtual IP addresses received by said load balancing controller that do not have 
corresponding indication in said address record as being configured as virtual IP addresses at any 
of said site switches , are treated as real IP addresses by said load balancing controller and are 
excluded from having applied thereto any metric of said load balancing algorithm that is usable 
with virtual IP addresses ." Accordingly, since the White Paper does not disclose, teach, or 
suggest the specific features recited in claims 34 and 37 directed towards a private virtual IP 
address and public virtual IP addresses, claims 34 and 37 are allowable. 

Dependent claim 38 specifies that said at least one metric is "an active bindings 
metric that prefers a virtual IP address, associated with any of said site switches, having a 
maximum number of active ones of said host servers bound to said preferred virtual IP address, 
rather than preferring another virtual IP address having a number of bound active ones of said 
host servers that is less than said maximum number." It is respectfully submitted that the 
limitations in claim 38 are not met by the White Paper. 

For example, in originally rejecting former claim 29, page 10 of the present 
Office Action cited page 4 (first bullet under "Maximum Server Utilization") of the White Paper 
as allegedly disclosing the "active bindings metric" recited in claim 29. This interpretation of the 
White Paper is respectfully traversed. The cited portion of the White Paper recites the following 
(emphasis ours): 
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" SLB is the general term assigned to techniques intended to 
provide: ... maximum server utilization ..." 

Server Load Balancing or "SLB" is a network configuration wherein a plurality of 
servers (a "server farm") sits behind a site switch. The servers of the server farm may be 
mapped to a virtual IP address configured on the site switch. The site switch receives traffic 
from clients that is addressed to the virtual IP address, and distributes/balances the traffic among 
its servers in the server farm. Thus, when the White Paper is speaking of "maximum server 
utilization" in the context of "SLB," a person skilled in the art would interpret this description as 
describing a situation where the site switch attempts to balance traffic as best as possible by 
ensuring that all of its available servers of the server farm are used for load distribution and that 
not any one or more servers of the server farm are disparately burdened with traffic relative to 
other servers in the server farm. 

Claim 38 pertains to a different situation than the SLB configuration and "server 
utilization" of the White Paper. Specifically, claim 38 states that the active bindings metric 
prefers a virtual IP address, associated with any of the site switches, having a maximum number 
of active host servers, rather than preferring another virtual IP address having a lesser number of 
active servers. Thus, claim 38 involves a situation where one virtual IP address is preferred over 
another virtual IP address based on the number of active host servers bound to them — this is 
different than the SLB configuration of the White Paper where there is only one (1) virtual IP 
address (e.g., the virtual IP address configured on the site switch) and only one set of servers (in 
the server farm) bound to that single virtual IP address. In other words, the White Paper does not 
compare two or more virtual IP addresses with each other to determine which virtual IP address 
has a greater number of active host servers bound to it — instead, the cited portion of the White 
Paper is merely speaking of load distribution among servers bound to the same virtual IP 
address. 

Thus, claim 38 is allowable over the White Paper. 
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IV. Discussion of other independent claims and their dependent claims 

New independent claim 39 and its dependent claims are method claims having 
recitations that generally parallel some of the recitations of claim 34 and its dependent claims, 
except written from the perspective of the load balance switch. For reasons similar to those 
explained above with respect to claim 34 and its dependent claims, claim 39 and its dependent 
claims are also allowable over the White Paper. 

Independent claims 43 and 47 (and their corresponding dependent claims) 
respectively include recitations generally parallel to those of claims 34 and 39 (and their 
corresponding dependent claims), and are allowable over the White Paper for similar reasons. 

Independent claim 5 1 and its dependent claims are directed towards a site switch, 
while independent claim 56 and its dependent claims are directed towards a load balance switch. 
These claims include recitations that generally parallel those previously explained above with 
respect to the other independent claims, and are allowable over the White Paper for similar 
reasons. 

V. Conclusion 

Overall, none of the references of record singly or in any proper combination 
disclose, teach, or suggest what is recited in the independent claims. Thus, given the above 
amendments and accompanying remarks, the independent claims are now in condition for 
allowance. The dependent claims that depend directly or indirectly on these independent claims 
are likewise allowable based on at least the same reasons and based on the recitations contained 
in each dependent claim. 

If the undersigned attorney has overlooked a teaching in any of the cited 
references that is relevant to the allowability of the claims, the Examiner is requested to 
specifically point out where such teaching may be found. Further, if there are any informalities 
or questions that can be addressed via telephone, the Examiner is encouraged to contact the 
undersigned attorney at (206) 622-4900. 
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The Director is authorized to charge any additional fees due by way of this 
Amendment, or credit any overpayment, to our Deposit Account No. 19-1090. 

All of the claims remaining in the application are now clearly allowable. 
Favorable consideration and a Notice of Allowance are earnestly solicited. 
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Redlined Substitute Specification 

GLOBAL SERVER LOAD BALANCING SUPPORT FOR PRIVATE VIP 

ADDRESSES 

BACKGROUND OF THE INVENTION 

Field of the Invention 

5 This disclosure relates generally to load balancing among servers. 

More particularly but not exclusively, the present disclosure relates to providing 
network components with capability to detect mapping between public and private 
addresses and to provide the public addresses for use in load balancing. 

Description of the Related Art 

10 Under the Transmission Control Protocol/Internet Protocol (TCP/IP), 

when a client provides a symbolic name (a Uniform Resource Locator or URL) to 
request access to an application program or another type of resource, the host 
name portion of the URL needs to be resolved into an IP address of a server for 
that application program or resource. For example, the URL (e.g., 

15 http://www.foundrvnet.com/indox. htm htto://www. foundrvnet. com/ index, htm) 
includes a host name portion www.foundrvnot.com www, foundrvnet. com that 
needs to be resolved into an IP address. The host name portion is first provided 
by the client to a local name resolver, which then queries a local Domain Name 
System (DNS) server to obtain a corresponding IP address. If a corresponding IP 

20 address is not locally cached at the time of the query, or if the time-to-live (TTL) of 
a corresponding IP address cached locally has expired, the DNS server then acts 
as a resolver and dispatches a recursive query to another DNS server. This 
process is repeated until an authoritative DNS server for the domain (e.g., 
foundrynet.com, in this example) is reached. The authoritative DNS server returns 

25 one or more IP addresses, each corresponding to an address at which a server 



hosting the application ("host server") under the host name can be reached. 
These IP addresses are propagated back via the local DNS server to the original 
resolver. The application at the client then uses one of the IP addresses to 
establish a TCP connection with the corresponding host server. Each DNS server 
5 caches the list of IP addresses received from the authoritative DNS server for 
responding to future queries regarding the same host name, until the TTL of the IP 
addresses expires. 

To provide some load sharing among the host servers, global server 
load balancing GSLB) switches are sometimes used as proxies for authoritative 

10 DNS servers, together with one or more site switches each associated with one or 
more host servers. Each site switch provides the GSLB switch with current site- 
specific information ("metrics") regarding access conditions to the host servers 
associated with the site switches. The GSLB switch then processes the addresses 
returned by the DNS server using the metrics compiled from the site switches and 

15 provides an ordered address list having the optimum address for access listed at 
the top. An example of a GSLB system and description of associated metrics are 
disclosed in U.S. Application Serial No. 10/376,903, entitled "GLOBAL SERVER 
LOAD BALANCING," filed February 28, 2003, assigned to the same assignee as 
the present application, and which is incorporated herein by reference in its 

20 entirety. 

An increasingly common feature of networks with internal and 
external connections is the mapping of private (internal) server addresses to public 
(external) addresses via a mapping device, such a firewall or Network Address 
Translation (NAT) device. Another frequent characteristic of such networks is the 
25 use of virtual IP addresses (VIPs) in addition to real server addresses. A VIP can 
have either or both a private address and a public address. The authoritative DNS 
server for which a GSLB switch is being used as a proxy for the specified domains 
is typically configured with the public addresses for these domains, so that the 
GSLB switch can reorder these public addresses returned in the authoritative DNS 



server reply as part of the GSLB algorithm when a client requests access to any of 
the specified domains. In addition to having a GSLB switch communicate directly 
with site switches to obtain metrics information from the site switches, the GSLB 
switch also receives from the site switches a list of VIPs configured on the site 
5 switches. If these VIPs are private IP addresses mapped to public IP addresses 
by a device such as a firewall or NAT device, then the site switch is unaware of the 
mapping and only communicates the private VIP addresses to the GSLB switch. 
However, since the authoritative DNS server is configured with the public 
addresses rather than with the private addresses, the public VIP addresses 

10 received in the DNS reply do not match the private VIP address on the GSLB 
switch and are treated as real addresses by the GSLB switch rather than as virtual 
addresses. Since most of the metrics are applicable only to virtual addresses and 
not to real addresses, the GSLB switch cannot apply many of the metrics to the 
received private address, thereby reducing the overall efficiency or accuracy of the 

15 load balancing system. 

As a further elaboration, a VIP having a private IP address is 
configured on a site switch. The site switch would know the private IP address 
associated with that VIP, but would not know the public IP address mapped to that 
private IP address by a mapping device (such as a firewall device). As a result, 

20 the site switch would communicate only the private IP address (and its associated 
metrics information) rather than the public IP address to the peer GSLB switch. 
Meanwhile, the authoritative DNS server (for which the peer GSLB switch is 
serving as a proxy and for which the GSLB switch is handling load balancing for 
the site having the VIP) has been configured with only the public IP address for the 

25 VIP for that site. Accordingly, when the GSLB switch receives the DNS reply from 
the authoritative DNS server, the GSLB switch would not recognize the public IP 
address in the DNS reply as being a VIP at that site, since the GSLB switch is only 
aware of the private IP address of the VIP received from the site switch. The 
GSLB switch therefore treats the received public IP address as a real address, 



since the private IP address is different from the public IP address in the DNS reply 
being reordered by the GSLB switch. Accordingly, the GSLB switch would not 
apply (or would incorrectly apply) some of the metrics, such as the active bindings 
metric (where the best IP address is the VIP that has the maximum number of 
5 active real servers bound to it), which are usable only with virtual addresses. Had 
the GSLB switch been able to correctly identify the received address as being a 
VIP, the GSLB would have been able to apply the correct metric(s) for VI Ps when 
reordering the reply from the authoritative DNS server for which it is serving as a 
proxy. 



10 BRIEF SUMMARY OF THE INVENTION 

One aspect of the present invention provides a method that includes 
obtaining information related to a mapping between first and second addresses 
associated with a network resource. The method sends the mapping information 
to a load balancing device to allow the load balancing device to load balance traffic 

1 5 to the network resource using at least one metric associated with the second 
address and the mapping information. 

The present invention is better understood upon consideration of the 
detailed description of the embodiments below, in conjunction with the 
accompanying drawings. 



20 BRIEF DESCRIPTION OF THE DRAWINGS 

Non-limiting and non-exhaustive embodiments of the present 
invention are described with reference to the following figures, wherein like 
reference numerals refer to like parts throughout the various views unless 
otherwise specified. 

25 Figure 1 illustrates a GSLB system in which an embodiment of the 

invention may be implemented. 



Figure 2 illustrates a GSLB system according to one embodiment of 
the invention with a remote load balancing arrangement. 

Figure 3 illustrates a GSLB system according to another embodiment 
of the invention with a combination of remote and local load balancing 
5 arrangement. 

Figure 4 illustrates a GSLB system according to yet another 
embodiment of the invention with a combination of remote and local load balancing 
arrangement. 

Figure 5 is a flowchart of a GSLB process to provide public 
10 addresses according to an embodiment of the invention for a remote load 
balancing arrangement. 

Figure 6 is a flowchart of a GSLB process to provide public 
addresses for only remote load balancing in an arrangement having both remote 
and local load balancing according to an embodiment of the invention. 
15 Figure 7 is a flowchart of a GSLB process to provide public 

addresses for both remote and local load balancing according to an embodiment of 
the invention. 

DETAILED DESCRIPTION 

Embodiments of techniques to provide GSLB support for private VIPs 

20 are described herein. In the following description, numerous specific details are given 
to provide a thorough understanding of embodiments of the invention. One skilled in 
the relevant art will recognize, however, that the invention can be practiced without 
one or more of the specific details, or with other methods, components, materials, etc. 
In other instances, well-known structures, materials, or operations are not shown or 

25 described in detail to avoid obscuring aspects of the invention. 

Reference throughout this specification to "one embodiment" or "an 
embodiment" means that a particular feature, structure, or characteristic described 
in connection with the embodiment is included in at least one embodiment of the 



present invention. Thus, the appearances of the phrases "in one embodiment" or 
"in an embodiment" in various places throughout this specification are not 
necessarily all referring to the same embodiment. Furthermore, the particular 
features, structures, or characteristics may be combined in any suitable manner in 
5 one or more embodiments. 

As an overview, one embodiment of the present invention provides 
GSLB support for private VIPs. According to this embodiment, an authoritative 
DNS server, for which a GSLB switch is serving as a proxy, is configured with 
public IP addresses for a domain that the GSLB switch load balances. A site 

10 switch for the GSLB switch is configured with one or more private address of a VIP 
of the domain, with the site switch providing metrics information to the GSLB 
switch as part of the load balancing process. A mapping device maps the private 
addresses of the VIP to the public IP addresses. 

The site switch obtains the mapping information from the mapping 

15 device, thereby being able to identify the public IP address of the VIP. The site 
switch then communicates all of the VIPs, configured on the site switch, to the 
GSLB switch. Because the site switch has identified the public IP address that is 
mapped to the private IP address configured on the site switch, the communication 
of the VIPs from site switch to the GSLB switch includes the public IP address 

20 instead of the private IP address. The GSLB switch receives the public IP address 
of the VIP from the site switch. The GSLB switch updates an address list/records 
it maintains for the site switch with the public IP addresses of the VIP. As a result, 
when the GSLB switch reorders the DNS reply from the authoritative DNS server, 
the GSLB switch references the address list and correctly identifies the IP address 

25 in the reply as a VIP on the site switch, since the IP address configured for the 
domain on the authoritative DNS server as well as that learned by the GSLB 
switch from the site switch now is the public IP address of the VIP. The GSLB 
switch is now able to apply the appropriate VIP-related metrics accurately to 
reorder the DNS reply to send to a requesting client. 



According to various implementations, the site switch can be 
configured "for peer only" or "for self and peer." With the "for peer only" 
configuration, a GSLB controller on the site switch continues to use private IP 
addresses if the site switch also performs GSLB for the local site. With the " for 
5 self and peer" configuration, the site switch communicates the public IP addresses 
to a peer GSLB switch as well as to a local GSLB controller if the site switch is also 
functioning as a GSLB switch, thereby allowing the local GSLB controller of the 
site switch to accurately apply VIP-related metrics to load balance traffic. 

Figure 1 shows one example of a global server load balancing 

10 arrangement in which an embodiment of the invention may be implemented. As 
shown in Figure 1, a remote (peer) GLSB switch 100 is connected to an Internet 
104 and acts as proxy to an authoritative DNS server 102 for a network 
represented by the domain "foo.com" (for example). While the DNS server 102 
provides the actual DNS service for the domain, the IP address known to the rest 

15 of the Internet 104 for the authoritative DNS server 102 is a VIP address 

configured on the GSLB switch 100. The DNS server 102 is also configured with 
the IP addresses for the domain foo.com, and the GSLB switch 100 is configured 
as a proxy for the domain foo.com. The GSLB switch 100 forwards client queries 
to the DNS server 102, and reorders the IP address list received from the 

20 authoritative DNS server 102 and sends the reordered IP address list in response 
to queries from clients requesting access to foo.com. 

The network represented by the domain name foo.com has two 
components, for the purpose of describing an embodiment of this invention, in 
addition to other sub-parts. These components are a mapping device 106 and at 

25 least one site switch 108 (or other network device, such as a router). The mapping 
device 106 translates internal (private) addresses of real and virtual servers on the 
network to external (public) addresses. NAT or firewall devices are typical 
examples of such mapping devices 106. 



The site switch 108 is coupled to an internal side of the mapping 
device 106. In addition to other tasks, the site switch 108 collects information 
about real and/or virtual servers 1 10 on the network and communicates with the 
GSLB switch 100. In particular, the site switch 108 has one or more VIPs 
5 configured on it, and communicates to the GSLB switch 100 that it has these VIPs 
via a protocol exchange. This protocol exchange is also used to communicate 
VIP-related metrics information collected by the site switch 108 to the GSLB switch 
100. 

In a global server load balancing application, the GSLB switch 100, 

10 acting as a proxy to the authoritative DNS server 102, receives a query from a 
client on the Internet 104 in the form of a URL that requests access to the domain 
foo.com, for example. The authoritative DNS server 102 provides a list of 
addresses to the GSLB switch 100 that corresponds to the domain foo.com. The 
GSLB switch 100 also gets metrics information along with a list of VIPs configured 

15 on the site switch 108 from the site switch 108. Using the metrics information, the 
GSLB switch 100 reorders the list of addresses received from the authoritative 
DNS server 102 to place the optimum address at the top. For purposes of brevity, 
details of global server load balancing and performance metrics for load balancing 
will not be described in further detail herein, and instead are disclosed in U.S. 

20 Application Serial No. 1 0/305,823, entitled "DISTRIBUTED HEALTH CHECK FOR 
GLOBAL SERVER LOAD BALANCING", filed November 27, 2002; U.S. 
Application Serial No. 10/376,903, entitled "GLOBAL SERVER LOAD 
BALANCING", filed February 28, 2003; and in U.S. Application Serial No. 
10/211,822, entitled "STATISTICAL TRACKING FOR GLOBAL SERVER LOAD 

25 BALANCING", filed August 1 , 2002. All applications are assigned to the same 
assignee as the present application and incorporated herein by reference in their 
entirety. 

In accordance with embodiments of the invention that will be 
described further below, the site switch 1 08 obtains mapping information between 



public and private IP addresses on the network from the mapping device 106 and 
then communicates the VIPs configured on the site switch 108 to the GSLB switch 
100, with the communication including the public IP address of the VIP rather than 
its private IP address. The GSLB switch 100 can then responsively update its 
5 address records 1 12 (e.g., a VIP list that the GSLB switch 100 maintains for the 
site switch 108) with the public IP address of the VIP. This public IP address of the 
VIP is also configured for the domain foo.com on the DNS server 102. The DNS 
server 102 returns a list of IP addresses, also containing the public IP address of 
the VIP, to the GSLB switch 100. The GSLB switch 100 refers to its address 

10 records 1 12 and correctly identifies the public IP address as a VIP on the site 

switch 108. Thus, the GSLB switch 100 can reorder the list of addresses received 
from the authoritative DNS server 102 based on the VIP-related metrics 
information and/or other metrics information provided by the site switch 108. 

Examples of suitable topographies for load balancing with private VIP 

15 support include, but are not limited to, the following three arrangements in Figures 
2-4. Figure 2 is a block diagram of a remote GSLB arrangement according to an 
embodiment of the invention. In this arrangement, a site switch 208 has no 
associated local GSLB sites and does not function as a GSLB switch itself (e.g., 
the site switch 208 has no local GSLB controller or metric collector). The site 

20 switch 208 operates as the remote site switch for a GSLB switch 200 (which load 
balances traffic to a network 224), and the GSLB switch 200 has no local site 
configured. Servers 210 have real IP addresses, and can have private VIP 
addresses configured on the site switch 208. 

The network 224 can have a variety of mapping device 

25 arrangements. No mapping device, a mapping device integrated with the site 
switch 208, or an external mapping device connected to the site switch 208 are 
some of the examples. A mapping device 206 is shown in Figure 2, which may be 
a firewall, NAT, or other device that maps or otherwise allocates public IP 
addresses to the private IP addresses configured on the site switch 208. The 



mapping information can be stored in one or more tables 220 or other data 
structure accessible by the site switch 208 in one embodiment. 

There are several techniques that may be employed to allow the site 
switch 208 to obtain the mapping between the private and public IP addresses. In 
5 one embodiment, the mapping can be obtained via user configuration information. 
In this embodiment, a user can explicitly configure (such as via programming) the 
site switch 208 with the particulars of the mapping between the public IP 
addresses and the private IP addresses. In another embodiment, the mapping 
device 206 is integrated with the site switch 208, and the site switch 208 can 

1 0 directly obtain the mapping information from the table 220 (internal) or other entity 
that is maintained with the allocation of public IP addresses to private IP 
addresses. In yet another embodiment, the site switch 208 can obtain the 
mapping information through a message communication 226 with the mapping 
device 206, if the mapping device 206 is external to the site switch 208. The 

15 message communication 226 can be unidirectional or bi-directional movement of 
data between the site switch 208 and mapping device 206. 

Then, the site switch 208 provides the obtained public IP addresses 
for the VIPs configured on it to the GSLB switch 200 that handles the remote load 
balancing for that particular network 224. According to one embodiment, the 

20 public IP addresses are provided to the GSLB switch 200 via a protocol message 
communication 222, along with related metrics information, instead of the private 
IP addresses. Alternatively or in addition in another embodiment, the information 
provided via the message communication 222 includes information indicative of 
the mapping between the public and private IP addresses, rather than solely the 

25 public IP addresses. 

A specific example is now provided with regards to operation of the 
arrangement of Figure 2. Also provided to assist in explaining the operation is 
Figure 5, which is a flowchart of a GSLB process to provide public addresses 
according to an embodiment of the invention for the remote load balancing 



arrangement of Figure 2. At least some components of the flowcharts depicted 
herein may be embodied in software or other machine-readable instructions stored 
on one or more machine-readable media. Such machine-readable media may be 
at a site switch, at a remote GSLB switch, or at other locations or combinations 
5 thereof. The various operations represented in the flowchart need not necessarily 
occur in the exact order depicted and some operations can be eliminated, added, 
or combined. 

Initially in this example, the user configures a VIP 192.168.10.1 on 
the site switch 208. The VIP address 192.168.10.1 is a private IP address. The IP 

1 0 addresses (public) for a domain www.Qslb.com www, aslb, com are 207.95.55.23 
and 253.72.96.55, and which are configured on the DNS server 202. The GSLB 
switch 200 is serving as a proxy to the DNS server 202 and is providing GSLB for 
the domain www.astb.com www, aslb. com . 

The mapping device 206 maps the private IP address 192.168.10.1 

1 5 of the VIP to one of the public IP addresses 207.95.55.23 (for example). The 
operations of Figure 5 begin with examples of different ways of providing mapping 
information to the site switch 208. Mapping information between the public and 
private IP addresses can be obtained by the site switch 208 via user configuration 
at a block 500, via access to internal allocation tables of an integrated mapping 

20 device at a block 502, via message communication with an external mapping 
device at a block 504, or via some other technique. Should the mapping 
information change at any time, the site switch 208 can re-learn the mapping. In 
addition to the mapping information (e.g., the public IP addresses), the site switch 
208 also collects related metrics information at a block 506. 

25 The site switch 208 is configured "for peer only" in this example, 

since the site switch 208 does not function as a GSLB controller/collector and does 
not have a local GSLB site configured. Therefore, the site switch 208 will be 
sending public IP addresses to the peer GSLB switch 200 only, to allow the peer 
GSLB switch 200 to perform load balancing accurately for the domain 



www.aslb.com www, aslb. com , rather than also sending public IP addresses to its 
internal GSLB components (which it does not have or are not enabled). The site 
switch 208, having obtained the mapping and metrics information, transmits that 
information to the GSLB switch 200 at a block 508. More specifically, the site 
5 switch 208 notifies the GSLB switch 200 that it has a VIP 207.95.55.23 configured 
on it. The GSLB switch 200 maintains a list (e.g., address records 212) of VIPs for 
each site switch, and at a block 510, updates the address 207.95.55.23 (to indicate 
that this address is a VIP) in the VIP list maintained for the site switch 208. 

A client makes a query to the GSLB switch 200 requesting access to 

1 0 www.aslb.Gom www, aslb. com at a block 51 2, with the IP addresses configured on 
the authoritative DNS server 202 for the domain www.aslb.com www, aslb. com 
being 207.95.55.23 and 253.72.96.55. The GSLB switch 200 forwards the request 
to the DNS server 202 at a block 51 1 , and the DNS server 202 sends an address 
list associated with the domain to the GSLB switch at a block 515 (i.e., the 

1 5 addresses 207.95.55.23 and 253.72.96.55 in this example). The GSLB site switch 
200 refers to the address records 212 at a block 513 and can now correctly identify 
that 207.95.55.23 is a VIP on the site switch 208, since the GSLB switch 200 now 
has this IP address in the VIP list maintained for the site switch 208. The GSLB 
site switch 200 then performs GSLB on these IP address using the applicable 

20 metrics and selects the best IP address from among the addresses 207.95.55.23 
and 253.72.96.55 at a block 514. Information reported by the site switch 208 can 
be used by the GSLB switch 200 for the VIP 207.95.55.23 during this selection 
process at the block 514, since the IP address 207.95.55.23 has been correctly 
identified as a VIP on the site switch 208. The final operation in the flowchart is 

25 the transmission of the ordered address list to the inquiring client at a block 516. 

In the load balancing arrangement depicted in Figure 3, both remote 
and local load balancing are performed, except that the arrangement is configured 
"for peer only," where public IP addresses are communicated only to a remote 
peer GSLB switch 300 from a site switch 308, which performs its own ("self) local 



GSLB but does not communicate public IP addresses to its own internal GSLB 
components. 

To further elaborate, the site switch 308 performs GSLB for one or 
more associated local sites 312 and remote sites (if any), and in addition is the site 
5 switch for the GSLB switch 300 that load balances traffic to a site 314 having host 
servers 310 coupled to the site switch 308. The site switch 308 is configured with 
the private VIP addresses to which the servers 310 of the site 314 are bound and 
obtains at 324 mapping information from a mapping device 306, which maps these 
private VIP addresses to public IP addresses. The public IP addresses are 

10 obtained from the mapping device 306 using techniques previously described 
above, and as before with reference to Figures 2 and 5, the public IP addresses 
are communicated (along with related metrics information) by the site switch 308 to 
the GSLB switch 300 via a protocol message communication 316, so that the 
GSLB switch 300 can update its VIP list with the public IP address of the VIP. 

15 The site switch 308 is also configured with the private IP addresses 

associated with the local site 312. However, since the site switch 308 is 
configured "for peer only," the site switch 308 does not send any public IP 
addresses associated with the local site 312 to the internal GSLB components 318 
(e.g., a local GSLB controller or metric collector) integrated within the site switch 

20 308. Rather, the site switch 308 sends the private VIP addresses configured on it 
to the internal GSLB components 318. 

An example description of the operation of the arrangement of Figure 
3 will now be provided in conjunction with a flowchart of Figure 6. The GSLB 
switch 300 provides GSLB for a domain www.aslb1.com www, aslbl. com . The 

25 public IP addresses configured for www.Qslb1.com www, gslbl. com on an 

authoritative DNS server 302 are 207.95.55.23 and 253.72.96.55. As explained 
above, the GSLB switch 300 does not have any local site configured, and has one 
remote site 314 with the site switch 308 (e.g., the site switch 308 is a site switch for 
the GSLB switch 300). 



In addition to being a site switch for the GSLB switch 300, the site 
switch 308 itself is also a GSLB switch that provides GSLB for a domain 
www.foo.com www, foo. com at the local site 312. The IP addresses configured 
for the domain www.foo.com www, foo. com on an authoritative DNS server 322 
5 are 192.168.10.1 and 192.168.72.1, which are private IP addresses. Accordingly, 
the site switch 308 provides GSLB for the domain uww.foo.com www, foo. com 
and is the local site switch used by its internal GSLB components 318. In addition, 
the site switch 308 operates as the remote site switch for the GSLB switch 300, 
which provides GSLB for the domain www.aslb1.com www, aslbt com . 
10 When the "for peer only" configuration is completed on the site switch 

308, the site switch 308 will do the following: 

1) Since the site switch 308 is a remote site switch for the GSLB 
switch 300, the site switch 308 will communicate the VIPs configured on it via the 
message communication 316 to the GSLB switch 300. In particular, the site switch 

15 308 obtains the mapping information including the public IP addresses for the site 
314 from the mapping device 306 at a block 600, and will notify the GSLB switch 
300 that the site switch 308 has a VIP 207.95.55.23 configured on it at a block 
602. The GSLB switch 300 maintains address records 320 of VIPs for each site 
switch and at a block 604, updates the VIP address as 207.95.55.23 in the VIP 

20 records maintained for the site switch 308. 

2) In addition, the site switch 308 is also a local site for the site switch 
308 operating as a GSLB switch. Therefore, the site switch 308 will communicate 
the VIPs configured on it to its internal GSLB components 318 (along with metrics 
information) at a block 606. However, since the user has configured the "for peer 

25 only" option for one of the private VIP addresses (say 192.168.10.1, for instance), 
the local site switch 308 will notify its internal GSLB components 318 that it has a 
private VIP 192.168.10.1 configured on it-note that it does not communicate the 
public IP address of the VIP to the internal GSLB components 318. 



A client makes a query fo r tviviv.foo.com www, foo. com , which the 
site switch 308 receives as a request to access the site 312 at a block 608, and 
forwards the request to the DNS server 322 at a block 609. The IP addresses 
configured for the domain www.foo.com www, foo. com on the DNS server 322 are 
5 192.168.10.1 and 192.168.72.1. The DNS server 322 sends the list of addresses 
containing 192.168.10.1 and 192.168.72.1 to the internal GSLB components 318. 
The internal GSLB components 318 refer to its address records 326 at a block 619 
and correctly identify that 192.168.10.1 is a VIP configured on the local site switch 
308, since the internal GSLB components 318 has this IP address in the VIP list it 

10 maintained for the site switch 312. The internal GSLB components 318 then 
perform GSLB on these IP addresses using the appropriate metrics and selects 
the best IP address for the client at a block 610. Metric information reported by the 
site switch 308 can be used by the internal GSLB components 318 for the VIP 
192.168.10.1 during the selection process at the block 610. The prioritized list of 

1 5 addresses is sent to the requesting client at a block 612. 

If a client makes a query for www.aslb1.com www, aslbl. com t o the 
GSLB switch 300 to request access to the site 314 at a block 614, the IP 
addresses configured for the domain www.aslb.com www, aslb. com on the DNS 
server 302 are 207.95.55.23 and 253.72.96.55. The GSLB switch 300 sends this 

20 request to the DNS server 302 at a block 61 5, and receives a list of addresses 
containing the addresses 207.95.55.23 and 253.72.96.55 from the DNS server 302 
at a block 617. The GSLB switch 300 refers to its address records 320 at the 
block 619, and correctly identifies that 207.95.55.23 is a VIP on the site switch 
308, since the GSLB switch 300 has this IP address in the VIP list maintained for 

25 the site switch 308. The GSLB switch 300 then performs GSLB on these IP 
addresses using the appropriate metrics and selects the best IP address for the 
client at the block 610. Information reported by the site switch 308 can be used by 
the GSLB switch 300 for the VIP 207.95.55.23 during the selection process at the 



block 610, since the IP address 207.95.55.23 has been correctly identified as a 
VIP on the site switch 308. 

Under another remote and local combination load balancing aspect 
of an embodiment of the invention shown in Figure 4, the site switch 308 can be 
5 configured "for self and peer," wherein public IP address are provided by the site 
switch 308 to both the peer GSLB switch 300 and the internal GSLB components 
318 integrated within the site switch 308. As with the embodiment of Figure 3, the 
remote GSLB switch 300 receives metric information regarding servers 310 from 
the local site switch 308 and performs the load balancing for the site 314. The 

10 local site switch 308 also acts as an independent GSLB switch for the local site 
312 and handles its load balancing based on the public IP addresses and metrics 
information received by its internal GSLB components 318 from other internal 
components 400 of the site switch 308. A requesting client would query the 
remote GSLB switch 300 for addresses of domains it is providing GSLB for. 

1 5 Similarly, the requesting client would query the GSLB controller at the site switch 
308 for addresses for domains the site switch 308 is providing GSLB for. 

Another example is now provided to illustrate operation of the 
arrangement of Figure 4 in connection with the "for self and peer" configuration, 
which is also to be described in connection with the flowchart of Figure 7. The 

20 GSLB switch 300 provides GSLB for the domain www.gslb1.com 

www, aslbl. com . The public IP addresses configured for www.gclb1.com 
www, aisbl. com on the DNS server 302 are 207.95.55.23 and 253.72.96.55. The 
GSLB switch 300 does not have any local site configured, and uses the site switch 
308 as its remote site switch. 

25 Additionally, the site switch 308 is also a GSLB switch providing 

GSLB for the domain www.foo.com www, foo. com , with the site switch 308 itself 
functioning as the site switch for its internal GSLB components 318. The public IP 
addresses configured for the domain www.foo.com www, foo. com on the DNS 



server 322 are 207.95.55.23 and 245.20.72.1, with the private IP address 
192.168.10.1 being mapped to the public IP address 207.95.55.23. 

When the "for self and peer" configuration is performed on the site 
switch 308, the site switch 308 will perform the following: 
5 1) Since the site switch 308 is a remote site switch for the GSLB 

switch 300, the site switch 308 will communicate the VIPs configured on the site 
switch 308 via the message communication 316 to the GSLB switch 300. In 
particular, the site switch 308 obtains (at 324 in Figure 4) the mapping information 
including the public IP addresses for the site 314 from the mapping device 306 at a 

10 block 700, and will notify the GSLB switch 300 that the site switch 308 has a VIP 
207.95.55.23 configured on it at a block 702. The site switch 308 also sends 
metrics information to the GSLB switch 300. The GSLB switch 300 maintains 
address records 320 of VIPs for each site switch, and at a block 704, updates the 
VIP address as 207.95.55.23 in the VIP records maintained for the site switch 308. 

15 2) In addition, site switch 308 is also a local site for the internal GSLB 

components 318. Therefore, components 400 will obtain mapping information 
between private and public IP addresses associated with the site 312 at a block 
706 and will communicate the VIPs configured on the site switch 308 to the 
internal GSLB components 318 at a block 708. Since user has configured the "for 

20 self and peer" option for the VIP 192.168.10.1, the internal components 400 will 
notify the internal GSLB components 318 that the VIP 207.95.55.23 is configured 
on the site switch 308 at the block 708--note that the public IP address of the VIP 
is communicated to the internal GSLB components 318. If necessary, address 
records 326 are updated by the internal GSLB components 318 to indicate that the 

25 public IP address 207.95.55.23 corresponds to a VIP on the site switch 308. 

The IP addresses configured for the domain www.foo.com 
www, foo. com on the DNS server 322 are 207.95.55.23 and 245.20.72.1 . If a 
client makes a query to the site switch 308 at a block 712 for the domain 
www.foo.co m www, foo. com , the site switch 308 forwards the request to the DNS 



server 322 at a block 713, and receives a list of addresses containing 
207.95.55.23 and 245.20.72.1. The internal GSLB components 318 refers to the 
address records 326 at a block 719, and correctly identify that 207.95.55.23 is a 
VIP on the local site switch 308, since this public IP address is now kept in the VIP 
5 list (e.g., the address records 326) maintained for the site switch 308. The internal 
GSLB components 318 then perform GSLB on these IP addresses using the 
appropriate metrics and selects the best IP address for the client at a block 714. 
Metric information reported by the site switch 308, or more particularly by the 
components 400, can be used by the internal GSLB components 318 for the VIP 

10 207.95.55.23 during the selection process at the block 714. 

The IP addresses configured for the domain www.gslb1.com 
www, aslbl. com on the DNS server 302 are 207.95.55.23 and 253.72.96.55. If a 
client makes a query to the GSLB switch 300 for the domain www.gelb1.com 
www, aslbl. com at a block 716, the GSLB switch 300 forwards the request to the 

15 DNS server 302 at a block 717, and receives a list of addresses containing 
207.95.55.23 and 253.72.96.55. The GSLB switch 300 refers to the address 
records 320 at the block 719, and correctly identifies that 207.95.55.23 is a VIP on 
the site switch 318, since this IP address in the VIP list {e.g., the address records 
320) maintained for the site switch 308. The GSLB switch 300 then performs 

20 GSLB on these IP addresses using the appropriate metrics and selects the best IP 
address for the client at the block 714. Information reported by the site switch 308 
can be used by the GSLB switch 300 for the VIP 207.95.55.23 during the selection 
process at the block 714, since the IP address 207.95.55.23 has been correctly 
identified as a VIP on the site switch 308. The prioritized list of addresses is sent 

25 to the requesting client at a block 718. 

All of the above U.S. patents, U.S. patent application publications, U.S. 
patent applications, foreign patents, foreign patent applications and non-patent 
publications referred to in this specification and/or listed in the Application Data Sheet, 
are incorporated herein by reference, in their entirety. 



The above description of illustrated embodiments of the invention, 
including what is described in the Abstract, is not intended to be exhaustive or to limit 
the invention to the precise forms disclosed. While specific embodiments of, and 
examples for, the invention are described herein for illustrative purposes, various 
5 equivalent modifications are possible within the scope of the invention and can be 
made without deviating from the spirit and scope of the invention. 

These and other modifications can be made to the invention in light 
of the above detailed description. The terms used in the following claims should 
not be construed to limit the invention to the specific embodiments disclosed in the 
10 specification and the claims. Rather, the scope of the invention is to be 
determined entirely by the following claims, which are to be construed in 
accordance with established doctrines of claim interpretation. 

15 
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